A fundamental problem of current robotics and in general software applications is related to multiple translations from natural language of task requirements to compiled and integrated working systems. It takes tremendous resources and multiple teams to define a task, translate requirements into Boolean logics of primitive algorithms and bake them together with generic and specific services of software applications. The resulting cake is too film in spite of its name—Software.
Current systems are programmed upfront to perform relatively simple, well defined and predictable tasks.
Robotics systems with adaptive behavior must be able to create new applications on-the-fly.
SOA paved the road to turn applications into service orchestrations.
Knowledge-driven architecture is a natural evolutionary step in this direction that allows us to streamline a transition from requirements to working systems and place business rules and scenarios into the driving seat of complex applications.
Evolution of Software Architecture:
Some of us still remember time when a single program could include video and disk drivers as well as data storage functionality mixed with application-specific code. Today, we call this mix “spaghetti code” but it was necessity those days when no operating system or other layers were present.
A new paradigm was created when database (DB) and operating system (OS) vendors took part in the process, and most software developers could focus on the application layer.
Today, the application layer continues to consist of a mixture of generic services and business specifics. Service-oriented and data-driven architectures, rules engines, and similar approaches helped clear this mess and paved the road for knowledge-driven architecture that combines SOA and Ontology and allows business intelligence to directly drive applications.
This new approach is based on three major factors:    1. Intelligent enterprise systems require new mechanisms, architecture, and implementation methods that can be described as distributed knowledge technologies [1] and are based on integrated software and knowledge engineering.    2. Service-oriented architecture, web services and related developments have allowed us to free service descriptions and service invocations from service implementation details.    3. Knowledge-driven architecture combines service orchestrations with rich ontology expressions supported by knowledgebase containers.
In knowledge-driven architecture (KDA), business rules and application scenarios are directly expressed in the knowledgebase in almost natural language and represent a thin application layer that drives the application. This architectural advance can allow an enterprise to shorten development time and produce smarter systems that can quickly accommodate themselves to rapid changes.
There are tremendous benefits of using knowledgebase with pre-defined fundamental concepts and generic facts, events, and scenarios, created by knowledge engineers as multiple layers of data, where the next data layer can only come on top of existing data. This is very similar to the way we, people, learn when our memory looks for associations of new facts with pre-existing background data.
The knowledge layer that we add to systems brings us closer to the point where we can delegate more tasks (beyond inventory and order applications) to computers.
Ontology and Predicate Logic vs. Boolean Logic
In our current software development process, we use the limited vocabulary of programming languages based on boolean logic and the limited (hierarchical) relationships of the object-oriented approach.
Ontology and Predicate Logic have unlimited vocabulary, which brings us closer to natural language and to multiple relationships, and therefore to real life.
We can express more complexity with fewer words.
The knowledgebase is not an empty container like a database, but is a smart partner with fundamental knowledge. We need only add our specifics to existing generic facts and rules.
These lines are generated by a system during a conversation with a subject matter expert who described system requirements. Let's imagine this conversation.
SME: “Only administrator can assign and change member roles”.
A system: “Can I rephrase it this way: Administrator authorizedToControl MemberRoles?”
SME: yes.
Conversational mechanism helps to translate situational requirements into close to natural language but more precise terms based on existing facts and rules. Each successful translation introduces another rule and increases the system power.
The integration of software and knowledge engineering is arriving on the scene in much the same way as object-oriented programming did when it replaced structural programming. Here are some of the most promising applications of this new approach:    1. Natural User Interface (NUI). Pattern recognition is applicable to images, voice, handwriting, and even translation from a foreign language. This makes a Natural User Interface (NUI), an interface selected by the user, a reality. You can type, use handwriting, or even speak with a foreign accent, and it will still be OK.    2. Direct Business. Subject matter experts will get the keys to development, and can directly enter their requirements as business rules and scenarios. End users will be able to change business rules and scenarios at run-time without asking for an upgrade or new project development.    3. Multiple factor resolution. When it comes to making a decision based on multiple factors, we have a hard time when the number of factors gets large. How many factors do you think you can handle? In such situations, we rarely find optimal or even good solutions. Applications powered by knowledge-driven architecture can help us here.    4. Smart data storage. Non-technical people will be able to use smart data storage platforms based on knowledge-driven architecture, while traditional storage mechanisms, like Oracle, can optimize back-end performance.    5. Common-sense applications. We can approach new tasks that require common-sense systems. Knowledge-driven architecture can accommodate such systems in a very affordable way.    6. Accelerated development tools. Development tool vendors will bring a new wave of tools for technical and not-so-technical people.    7. Distributed Knowledge Marketplace. Knowledgeable people tend to learn more and share their knowledge. Knowledge-powered systems will demonstrate similar behavior. Built-in to every Knowledge-Driven Architecture system, the distributed network communicator component can help connect the systems into distributed knowledge networks with simplified and more intuitive user-computer interaction. New ways to exchange and share knowledge and services will create markets that are distributed over the globe, and available to everyone who has privileges to contribute and consume data and services. New levels of collaboration will require new motivation and security mechanisms to enable distributed active knowledge networks.    8. A new world of applications and business markets.
One of the most interesting and promising opportunities is related to robotic systems. The invention improves robot-human interface and provides on-the-fly translation of situational requirements into adaptive behavior models and further down to service orchestrations for a team of robots.
Robots in knowledge-driven architecture are represented as a hierarchical system of controllers, where each controller offers its own set of services. Service descriptions, primitive and composite service orchestrations are collected in a Service Dictionary (SOA Dictionary) that provides a convenient conversational interface that helps to map changing requirements to new created on-the-fly behavior models to be communicated to robots as service orchestrations.
Robots as Hierarchical Controllers
An example in the FIG. 4, (see drawings) provides a simple illustration on how a human request is translated on-the-fly into a set of orchestrated services executed by a robot system.
A subject matter expert asks a robot system to clear the mine field. This command is interpreted by a system as a set of orchestrated service scenarios. Each scenario is communicated to a proper controller that execute the service or/and provides further interpretation down the line of controlled devices.